fix: avoid u32 overflow in statistics for full bitmaps - #358

Tested on top of current main (0439d57):

• On main and 0.11.5, RoaringBitmap::full().statistics() panics at statistics.rs:92 ("attempt to add with overflow") in a debug build. In release it silently reports n_values_run_containers: 0. With this branch it's 4294967296 in both, and statistics_full_run fails on main and passes here.
• Other bitmaps are unaffected. The Statistics output is identical on main and this branch for empty, 1M random, dense, run-heavy, mixed, half-range and full-minus-two bitmaps. (Only an exactly-full bitmap overflows; 2^32 − 1 values still fit.) cargo test -p roaring passes, and the branch merges cleanly into main.

One note for release planning: changing a public field's type is a breaking change. let n: u32 = stats.n_values_run_containers; compiles against 0.11.5 and fails with E0308 here, so this probably belongs in the next minor (0.12) rather than a 0.11.x patch. Also, only the run field can actually overflow: array containers hold at most 4096 values, so n_values_array_containers tops out at 65536 × 4096 = 2^28.

Restored n_values_array_containers to u32 in ffd45be, with a typed regression covering values across two array containers. The run count stays u64 so a full bitmap reports 2^32. I also removed the redundant conversion flagged by Clippy and corrected the description. The run-field type change still needs a release that permits a breaking API change.